IBIS Macromodel Task Group

Meeting date: 03 oct 2006

Members (asterisk for those attending):
* Arpad Muranyi, Intel Corp.
* Barry Katz, SiSoft
* Bob Ross, Teraspeed Consulting Group
* Doug White, Cisco Systems
* Hemant Shah, Cadence Design Systems
* Ian Dodd, Mentor Graphics
* Joe Abler, IBM
* John Angulo
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
* Kumar, Cadence Design Systems
  Lance Wang, Cadence Design Systems
* Michael Mirmak, Intel Corp.
* Mike LaBonte, Cisco Systems
  Paul Fernando, NCSU
* Randy Wolff, Micron Technology
* Richard Ward, Texas Instruments
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence
* Todd Westerhoff, Cisco Systems
* Walter Katz, SiSoft
  Vuk Borich, Agilent

-------------
Review of ARs:

- Redo calendar invitations to this meeting.
  Calendar invitations are redone.  Dropped Todd's Meetme info and added Mike Labonte's (Mike LaBonte)

- Richard see if Xilinx can join us.
  Richard invited a couple of people from Xilinx as well as some from STMicro (Ottawa).  Expected them to call in.

- Macro Library Documentation
  Hope to finish this by the end of the year.
  Mike L. has some schedule conflicts until November 7th, better after then.

-------------
New Discussion:

Arpad has given Mike Labonte a new VHDL-AMS library (precompiled) to post to the website.

AR:  Mike to post this week.

Next discussion concerned the apparent progress we have made in previous discussions surrounding the API proposal, among other things.
This discussion began with the general idea that has been discussed regarding the fact that we may be able to use a "divide and 
conquer" approach to make progress.  That is, perhaps we could use more typical IBIS or AMS driver and receiver models in order to 
generate the pulse response.  The driver model would need to be able to handle preemphasis, and the receiver model would simply be an
equivalent load-model.

Walter said that SiSoft is in the process of verifying that this simple representation of drivers is sufficient at these very high
frequencies.  He summarized his view of the current state of this simple driver modeling, stating that some are describing the
drivers with 
	-Driver impedance
	-Voltage swing(s)
	-Ccomp
	-Macro libraries...

Kumar stated that the basic purpose of the API is based on the view of the driver and receiver as "signal processing entities", and
as such the API is proposed as the best way to handle such entities.

Arpad reviewed the previous discussion concerning the divide-and-conquer approach, with the two general steps:
	1.  Driver and Receiver analog behavior to produce the pulse response could be modeled with existing techniques.
	2.  The sophisticated behavior of circuits could be summed up as:
		- Receiver Equalization algorithms
		- Receiver Clock Recovery systems
		- Possibly adaptive FIR filtering for the Drivers

It was stated that in any implementation, the taps for equalization should be made available to the simulator, so that
optimization might be enabled.

Michael Mirmak brought up a very basic question:  Are we trying to keep IBIS/AMS as a standard based in the realm of 
describing circuit-based behavior, or are we thinking of making it a signal processing standard as well?

Arpad reiterated:  It appears right now that we need to separate the electrical aspects of the models from the signal processing 
aspects of the models.  If this is so, then current techniques are capable of handling the electrical portion.  Then the question
becomes:  What is the API for the signal processing function?

Some brief discussion about how to get the tap-coefficient information into the IBIS structure, and a "parameter selector" statement
was brought up as an example.

Walter said that his sense is that AMS cannot handle the sophisticated receiver algorithms.  Ian thinks that AMS is most definitely
up to the task, but perhaps a bit inconvenient.  Do we need to decide whether AMS can handle this or not?  Regarding the convenience
issue, there are a couple of existing linear simulator tools out there that do not support AMS.

Current pervasive practice is behavioral modeling, mostly in Matlab.  Kumar noted that Cadence wanted to allow for this existing
infrastructure, and provide an API to make it easier to provide the models/algorithms.

There was a proposal to start a BIRD for the driver model changes necessary to handle such things as preemphasis, at least to 
break the gridlock and get started down a path.

AR:  Kumar suggested writing up the API architecture in a more formal way, so that the boundaries and partitioning of function could
be discussed more intelligently.

Near the end of the meeting, Joe Abler stated that he was concerned about the accuracy of these "circuit-based" models used to
generate the pulse response.  There was some ensuing confusion about what the concerns were actually about, and Arpad asked
whether the "divide and conquer" approach mentioned above was actually desirable or not.

AR:  Joe Abler to describe in more detail his fundamental concerns with this approach.

Arpad asked the group if anyone would step up and start offering concrete proposals for the next meetings.


-------------

Next meeting: Tuesday 10 Oct 2006 12:00pm PT